Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pull-based behaviors? #131

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

avieth
Copy link

@avieth avieth commented Mar 31, 2016

The motivation: when doing DOM programming we sometimes wish to deal
with the dimensions of elements. It seems natural to say that there is a
Behavior Rect for an element's bounding client rectangle. But how to
construct such a thing?? We would need an event to give the changes, but
the DOM doesn't supply that, and polling it would probably grow
prohibitively expensive. Why not compute it on-demand?

This patch defines fromPull :: IO a -> MomentIO (Behavior a) to
produce pull-based behaviors. Ideally, the IO would run at most once
per evaluation of the network. In this implementation, it's run at
least 0 times. I have a feeling I'm doing something horribly wrong in
newLatchIO.

What do you think? Good idea? Not so good? Consider this a feature request with code attached.

The motivation: when doing DOM programming we sometimes wish to deal
with the dimensions of elements. It seems natural to say that there is a
`Behavior Rect` for an element's bounding client rectangle. But how to
construct such a thing?? We would need an event to give the changes, but
the DOM doesn't supply that, and polling it would probably grow
prohibitively expensive. Why not compute it on-demand?

This patch defines `fromPull :: IO a -> MomentIO (Behavior a)` to
produce pull-based behaviors. Ideally, the IO would be run at most once
per evaluation of the network. In this implementation, it's run at
least 0 times.
@HeinrichApfelmus
Copy link
Owner

Sorry for taking so long to have a look at this, and sorry that I can only triage this at the moment.

I think the idea is interesting and useful.

Note that the implementation of fromPull does not need a LatchWriter, the purpose of the latter is only to connect a Pulse and a Latch. In this case, everything can be implemented within the Latch record. The reason why your code does not work is probably that the _seenL value is not updated.

I think a correct implementation would simply be to apply cachedLatch to an IO action (lifted into the EvalL monad).

@mitchellwrosen
Copy link
Collaborator

Could this concept simply replace fromPoll? fromPull has the same type signature, and pulling only wen necessary seems preferable to polling on every input event.

@mitchellwrosen
Copy link
Collaborator

mitchellwrosen commented May 27, 2018

Note that the implementation of fromPull does not need a LatchWriter, the purpose of the latter is only to connect a Pulse and a Latch. In this case, everything can be implemented within the Latch record. The reason why your code does not work is probably that the _seenL value is not updated.

I think a correct implementation would simply be to apply cachedLatch to an IO action (lifted into the EvalL monad).

I believe if you implement this feature only with cachedLatch, the IO action will be performed as many times as the latch is evaluated. For example,

b <- fromPull (print 5)
e1 <- b <@ someEvent
e2 <- b <@ someEvent

reactimate (print 10 <$ e1)
reactimate (print 20 <$ e2)

Here, ideally the action print 5 would only be performed once. But because it's sampled by two different events, this would print

5
10
5
20

when someEvent fires.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants